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(54) System, method and device for security processing of data packets 



(57) Methods and associated systems provide se- 
cured data transmission over a data network. A security 
device provides security processing in the data path cf 
a packet network. The device may include at least one 
network interface to send packets to and receive pack- 
ets from a data network and at least one cryptographic 
engine for performing encryption, decryption and/or au- 
thentication operations. The device may be configured 
as an in-line security processor that processes packets 
that pass through the device as the packets are routed 
to/from the data network. 
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Description 

CROSS-REFERENCE TO RELATED APPLICATIONS 

[0001] This application claims the benefit of U.S. Pro- s 
visional Patent Application No. 60/431 ,087, the disclo- 
sure of which is hereby incorporated by reference here- 
in. 

[0002] This application is relate d to U.S. Patent Ap- 
plication No. entitled TAGGING 

MECHANISM FOR DATA PATH SECURITY 
PROCESSING, filed on even date herewith and as- 
signed to the same assignee as this application, Attor- 
ney Docket No. 48946/SDB/B600, the disclosure of 
which is hereby incorporated by reference herein. 

FIELD OF THE INVENTION 

[0003] The invention relates generally to the field of 
data communications and, more particularly, to systems 
and methods for providing secured data transmission 
over data networks. 

BACKGROUND 

[0004] The transmission of data over a data network 
typically involves sending messages between applica- 
tion programs ("applications") executing on host proc- 
essors connected to the data network. In a packet net- 
work such as the Internet a host processor encapsulates 
data from an application into data packets (e.g., frames) 
to send the data over the packet network. When a host 
processor receives the data packet from the packet net- 
work, the host processor un encapsulates the packets to 
obtain the data. The host processor the n provides the 
data to the appropriate application. 
[0005] The process of encapsulating data into a pack- 
et involves adding information such as source and des- 
tination addresses to the data to facilitate transmission 
of the data over the packet network. Conventionally, the 
encapsulation process follows a particular packet data 
protocol. A typical protocol defines the structure of a 
packet such as the location of the source address and 
the destination address in the packet. A protocol also 
may define procedures for routing the packet over the 
network using those addresses. For example, the com- 
ponents in a data network may use the destination ad- 
dress to determine where to send the packet. The re- 
cipient application may use the source address to de- 
termine which application sent the packet. 
[0006] Common protocols used in conjunction with 
the Internet include Internet protocol ("IP"), transmission 
control protocol ("TCP"), user datagram protocol 
("UDP") and Internet control message protocol ("IC- 
MP"). In general, IP relates to controlling data transfer 
between host processors, TCP relates to establishing 
sessions to transfer data between applications, UDP 
provides a faster but less reliable data transfer mecha- 



nism than TCP, and ICMP relates to error messages and 
network traffic statistics. 

[0007] Data transmitted over public networks such as 
the Internet may be encrypted to prevent unauthorized 
parties from intercepting the data. Typically, a device 
connected to the network encrypts data using a cipher 
algorithm and an encryption key. The device sends the 
encrypted data over the network to another device that 
decrypts the data using the cipher algorithm and a de- 
cryption key. 

[0008] Several standards have been developed to fa- 
cilitate secure data transmission over data networks. 
For example, the Internet security protocol ("IPsec") 
may be used to establish secure host-to-host pipes and 
virtual private networks over the Internet. IPsec defines 
a set of specifications for cryptographic encryption and 
authentication. IPsec also supports several algorithms 
for key exchange, including an Internet Key Exchange 
("IKE") algorithm for establishing keys for secure ses- 
sions established between applications. 
[0009] Some systems include dedicated devices that 
offload some of the processing operations from the host 
processor. For example, a network processor may be 
used to perform some of the packet processing opera- 
tions. A cryptographic accelerator may be used to per- 
form the cipher algorithms to offload encryption/decryp- 
tion/authentication processing from the host processor. 
[0010] In a typical system, the primary data flow is 
from the host processor to the network processor then 
to the network, and vice-versa. In addition, the host 
processor or network processor routes packets that will 
be encrypted or de crypted to the cryptographic accel- 
erator. The cryptographic accelerator then routes the 
encrypted or decrypted packets back to the host proc- 
essor or network processor. In personal computer- 
based systems, the host processor, network processor 
and cryptographic accelerator typically are connected 
via a peripheral component interface ("PCI") bus. 
[0011] Conventional PCI -resident cryptographic en- 
gines (e.g., cryptographic accelerators or processors) 
have several disadvantages. For example, the data may 
be subject to additional round trips over the host bus. 
That is, the data may be routed over the PCI bus several 
times to pass the data to various components that proc- 
ess the data. In addition, the use of an independent de- 
vice for the cryptographic engine adds a re latively sig- 
nificant cost to the host system. Furthermore, it may be 
relatively difficult to implement such a system in tandem 
with a TCP offload engine (or a Layer 5 device) because 
IPsec is a Layer 3.5 process that, in effect, would sit in 
the midst of the TCP offload engine ("TOE"). 
[0012] Also, integration of the cryptographic engine 
into an Ethernet controller may add significant cost to 
the Ethernet controller. Given that the extent of the mar- 
ket's adoption of cryptography may be significantly less 
than the market's adoption of Ethernet controllers, such 
integration may not be economically justifiable. 
[0013] Coupled with the need to improve the operat- 
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ing speed and lower the cost of conventional crypto- 
graphic technology in general, there is a need to provide 
cry ptographic processing to support faster data trans- 
fers defined by various data communication standards. 
In an attempt to address the perpetual need for faster 
data communications, various groups are continuously 
developing standards that specify high -speed data 
transfers between components of data communication 
systems. For example, IEEE standards 802.3ab and 
802.3z define Ethernet systems for transferring data at 
rates up to one gigabit per second (1 Gbit/s). IEEE 
standard 802.3ae defines an Ethernet sys tern for trans- 
ferring data at rates up to 10 Gbits/s. 
[0014] The development of these standards and the 
ever increasing need for faster data transfers create a 
need for techniques and circuits capable of achieving 
high data transfer rates in a secure environment. More- 
over, there is an ever-present economic motivation to 
achieve such results in a cost effective and adaptable 
manner. Accordingly, a need exists for improved data 
security processing techniques to support data trans- 
mission over data networks. 

SUMMARY 

[0015] The invention relates to methods and associ- 
ated systems for providing secured data transmission 
over a data network. For example, a device constructed 
according to the invention may provide security 
processing in the data path. Thus, the device may in- 
clude at least one network interface to send packets to 
and receive packets from a data network and at least 
one cryptographic engine for performing encryption 
and/or decryption and/or authentication operations. For 
convenience, the encryption and/or decryption and/or 
authentication operations may be abbreviated herein as 
encryption/decryption/authentication , etc. 
[0016] Moreover, a device constructed according to 
the invention may be configured as an in-line security 
processor so that it processes packets that pass through 
the device, as the packets are being routed through the 
data network. Thus, packets from the network passing 
through the device are intercepted, then encrypted and/ 
or decrypted and/or authenticated as necessary, then 
forwarded out onto the network. 
[0017] In some embodiments, the in -line security 
processor may be, in effect, transparent to associated 
host processing components. For example, in some em- 
bodiments, the security processor is located between a 
network controller and a network connection. Here, the 
security processor may perform IPsec operations on in- 
bound or outbound packet traffic with little or no involve- 
ment by the host processor and/or network controller. 
[001 8] For example, the security processor may proc- 
ess incoming IPsec packets by processing the IPsec 
header information, locating locally stored security as- 
sociation information using information from the pack- 
ets, performing the appropriate cryptographic opera- 



tions, and removing the IPsec header and trailer and ad- 
justing IP header fields. Thus, the security processor 
sends standard, unencrypted TCP/IP packets to the net- 
work controller and the host processor. 

5 [0019] For outbound packets, a system may incorpo- 
rate varying degrees of interaction between the host 
processor, network controller and security processor. In 
one embodiment, the security processor is essentially 
transparent to the other components. Here, the security 

10 processor receives TCP/IP packets from the network 
controller, autonomously performs the cryptographic 
operations and adds the appropriate IPsec header and 
trailer to the packet. In another embodiment, the host 
processor and/or network controller add information to 

15 the packets sent to the security processor. This informa- 
tion may, for example, indicate which security associa- 
tion is to be used to encrypt/authenticate the packet. In 
another embodiment, the host processor and/or net- 
work controller adds the appropriate IPsec header and 

20 trailer to the packet. In this case, the security processor 
performs the cryptographic operations, updates the 
IPsec header and trailer and changes the payload, if 
necessary. 

[0020] One embodiment of a system constructed ac- 

25 cording to the invention relates to an Ethernet security 
processing system including a host processor, an Eth- 
ernet controller and an in - line security processor. Pack- 
ets flow from the host processor and Ethernet controller 
over a network connection to the in - line security proc- 

30 essor, then out to the network. In a similar manner, pack- 
ets from the network flow through the in - line security 
processor then over a network connection to the Ether- 
net controller and host processor. In one embodiment, 
the in -line security processor analyzes information in 

35 the received packets to determine whether the packets 
are to be encrypted/decrypted/authenticated or are to 
be forwarded through the in -line security processor. In 
one embodiment, the in -line security processor analyz- 
es flow information in the packets to identify the appro- 

^o priate security association information that is to be used 
to encrypt/decrypt/authenticate the packets. 
[0021] In the embodiments discussed in the above 
paragraph, the in-line security processor may, in effect, 
be essentially transparent to the Ethernet controller. For 

45 example, the Ethernet controller may not need to be 
adapted to cooperate with the in-line security processor. 
[0022] In another embodiment of a system construct- 
ed according to the invention, the Ethernet controller 
and/or host processor performs operations that enable 

so the security processor to more efficiently locate security 
associat ion information that is to be used to encrypt/ 
decrypt/authenticate packets. For example, the Ether- 
net controller may identify the flow associated with a 
packet and generate information relating to the security 

55 association for that flow. The Ethernet controller may 
then send that information with the packet to the security 
processor. 

[0023] One embodiment of this aspect of the invention 
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relates to adding one or more headers to a standard 
TCP/IP packet to provide an efficient manner for a se- 
curity processor to locate security association informa- 
tion for a packet. Such headers may include, for exam- 
ple, an Ethernet header including the address of the se- 
curity processor and a security frame header including 
a reference to an address of a security association. The 
security processor may then use the reference to re- 
trieve security association information from a local data 
memory. 

[0024] In some embodiments, the in -line security 
processor processes information in packets received 
from the network to locate security association informa- 
tion that is to be used to encrypt/decrypt/authenticate 
the packets. In one embodiment, the security processor 
uses a security parameter index ("SPI") embedded in 
the packet to locate security association information 
stored in a table in a data me mory located in or asso- 
ciated with the security processor. In one embodiment, 
the security processor hashes flow information embed- 
ded in the packet to locate the security association in- 
formation in the table. 

[0025] In one embodiment of a system constructed 
acco rding to the invention the security processor in- 
cludes at least one MAC/PHY interface to interface with 
an Ethernet network. In some embodiments, these in- 
terfaces are gigabit MAC/PHY interfaces that can inter- 
face with a gigabit Ethernet network. 
[0026] One embodiment of a system constructed ac- 
cording to the invention includes a gigabit Ethernet con- 
troller in combination with a gigabit security processor. 
The gigabit security processor performs IPsec opera- 
tions. The gigabit Ethernet controller provides the net- 
work interface for a host processor and may also per- 
form IP and TCP processing for the host processor. In 
this case, the gigabit Ethernet controller may send data 
flow information to the security processor to assist the 
security processor in performing IPse c operations. For 
example, the data flow information may include an ad- 
dress of security association data (e.g., encryption/de- 
cryption/authentication keys) associated with each data 
flow. In one embodiment, the data flow information is 
sent in a packet header that encapsulates the packet to 
be encrypted/decrypted/authenticated. 
[0027] In one embodiment of a system constructed 
according to the invention a security processor may be 
configured using packets sent over the data network. 
For example, the security processor may be configured 
with IPsec configuration packets. Hence, a host proces- 
sor may manage the security processor over a network. 
This may eliminate a need for an external processor for 
configuring the security processor. Moreover, the host 
processor may configure the security processor without 
specific "knowledge" of the physical location of the se- 
curity processor. Rather, the host processor may simply 
send configuration packets to its network controller. The 
network controller may then, in turn, fo rward the pack- 
ets to the security processor via the network. 



[0028] In one embodiment of a system constructed 
according to the invention one or more security proces- 
sors may be configured to support one or more host 
processors and/or Ethernet controllers. For example, 

5 packets for several host processors and/or Ethernet 
controllers may be sent through a switch that, in turn, 
routes the packets to/from a single security processor. 
Also, several security processors may be used to sup- 
port IPsec processing for high da ta rate networks (e.g., 

10 10Gbits/s). 

[0029] By providing network connectivity with the se- 
curity processor, it should be appreciated that a system 
constructed according to the invention may locate the 
cryptography components throughout a network. For 

is example, in some embodiments a security processor 
may be co -located with a network controller (e.g., Eth- 
ernet controller). In some embodiments, a security proc- 
essor and a network controller may be located on differ- 
ent sides of one or more switches. 

20 [0030] A system construe ted according to the inven- 
tion may provide high performance in-line cryptography 
that may operate seamlessly with a higher layer control- 
ler such as TOE, iSCSI, RNIC, etc. In implementations 
where cryptography is not needed, this architecture may 

25 add no cost to the implementations since the other sys- 
tem components may not need to be modified to support 
cryptography. For example, in some embodiments no 
modifications are made to the network controller. 
Hence, the cost of the network controller is not affected. 

30 in some embodiments, negligible modifications are 
made to the network controller to support cryptography 
(e.g., IPsec). These embodiments simplify the design of 
the cryptography (e.g., the security processor) thereby 
providing lower cost cryptography while adding relative- 

35 |y negligible cost to the network controller. Moreover, the 
cryptography may be implemented in a flexible manner 
as it may be co located or reside on a locally accessible 
and physically or logically secured network. 
[0031] According to an aspect of the invention, there 

40 is provided a security processing method comprising: 

receiving, by a security processor, packets from a 
Gigabit Ethernet network; 
processing at least a portion of the received pack- 
45 ets, the processing consisting of at least one of the 
group of encrypting, decrypting and authenticating; 
and 

transmitting, from the security processor, at least 
one result of the processing of the at least a portion 
so of the received packets. 

[0032] Advantageously, processing comprises per- 
forming IPsec operations. 

[0033] Advantageously, the IPsec operations com- 
55 prise adding or removing protocol elements. 

[0034] Advantageously, at least a portion of the re- 
ceived packets comprise security association informa- 
tion for use in encrypting, decrypting or authenticating 
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the at least a portion of the received packets. 
[0035] Advantageously, the method further compris- 
es the step of retrieving security association information 
from at least one data memory, wherein processing 
comprises encrypting, decrypting or authenticating the 
at least a portion of the received packets using the se- 
curity association information. 
[0036] Advantageously, the at least a portion of the 
received packets comprise at least one reference to an 
address of a security association, the method compris- 
ing the step of retrieving security association information 
from at least one data memory according to the address, 
wherein processing comprises encrypting, decrypting or 
authenticating at least a portion of the received packets 
using the security association information. 
[0037] Advantageously, the security processor com- 
prises an integrated circuit. 

[0038] According to another aspect of the invention, 
a security processor is provided comprising: 

at least one Gigabit MAC; and 
at least one processor, connected to send data to 
and receive data from the at least one Gigabit MAC, 
for encrypting, decrypting or authenticating at least 
a portion of the data. 

[0039] Advantageously, the at least one processor 
comprises at least one IPsec processor. 
[0040] Advantageously, the IPsec processor adds 
IPsec protocol elements to or removes IPsec protocol 
elements from the data. 

[0041] Advantageously, the processor further com- 
prises at least one processor for processing at least one 
frame header from the received data to extract security 
association information. 

[0042] Advantageously, the processor further com- 
prises at least one data memory for storing security as- 
sociation information for use by the at least one proces- 
sor. 

[0043] Advantageously, the processor further com- 
prises at least one processor that extracts security as- 
sociation information from data received from the at 
least one Gigabit MAC and that sends the security as- 
sociation information to the at least one processor. 
[0044] Advantageously, the processor further com- 
prises at least one processor for: 

extracting at least one address of at least one se- 
curity association from data received from the at 
least one Gigabit MAC; and 
sending the at least one address to the at least one 
processor; 

wherein the at least one processor: 

retrieves security association information from a da- 
ta memory according to the at least one address; 
and 



8 

encrypts, decrypts or authenticates packets using 
the security association information. 

[0045] Advantageously, the security processor is an 
s integrated circuit. 

[0046] According to another aspect of the invention, 
an in-line security processor is provided comprising: 

a plurality of Gigabit MACs; and 
10 at least one processor, connected to receive data 
from at least one of the Gigabit MACs and to send 
data to at least one of the Gigabit MACs, for encrypt- 
ing, decrypting or authenticating at least a portion 
of the data. 

15 

[0047] Advantageously, the at least one processor 
comprises at least one IPsec processor. 
[0048] Advantageously, the IPsec processor adds 
IPsec protocol elements to or removes IPsec protocol 
20 elements from the data. 

[0049] Advantageously, the processor further com- 
prises at least one processor for processing at least one 
frame header from the received data to extract security 
association information. 
25 [0050] Advantageously, the processor further com- 
prises at least one data memory for storing security as- 
sociation information for use by the at least one proces- 
sor. 

[0051] According to another aspect of the invention, 
30 a security processing system comprises: 

at least one media access controller; 
at least one security processor; and 
at least one switch for distributing or collecting pack- 
35 ets between the at least one media access control- 
ler and the at least one security processor. 

[0052] Advantageously, the at least one media ac- 
cess controller comprises at least one Gigabit MAC. 
40 [0053] Advantageously, the system further comprises 
at least one processor for allocating memory space as- 
sociated with security associations used by the at least 
one security processor. 

[0054] Advantageously, the at least one switch asso- 
45 ciates VLAN tags with the at least one media access 
controller. 

[0055] Advantageously, the at least one media ac- 
cess controller sends packets comprising security as- 
sociation information to the at least one security proc- 
so essor. 

[0056] Advantageously: 

the at least one media access controller sends 
packets comprising at least one address of at least 
55 one security association to the at least one security 
processor; and 

the at least one security processor retrieves secu- 
rity association information from a data memory ac- 
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cording to the at least one address and encrypts or 
authenticates packets using the security associa- 
tion information. 

[0057] According to another aspect of the invention, 5 
a chassis-based switch comprises: 

at least one backplane; 

at least one processing blade connected to the at 
least one backplane, the at least one processing 10 
blade comprising at least one media access con- 
troller; and 

at least one switching blade connected to the at 
least one backplane, the at least one switching 
blade comprising: is 

at least one security processor; and 
at least one switch for routing packets between 
the at least one media access controller and the 
at least one security processor. 20 

[0058] According to another aspect of the invention, 
a security processing system comprises: 

at least one media access controller for: 25 

executing TCP operations; 

generating information associated with at least 

one security association; and 

generating at least one packet including the in- 30 

formation; and 

at least one security processor, connected to re- 
ceive the at least one packet from the at least one 
media access controller for: 35 

locating the at least one security association 
using the information; and 
encrypting, decrypting or authenticating data 
using the security association. *o 



information associated with the TCP opera- 
tions; 

generating information associated with at least 
one security association from the context infor- 
mation; and 

generating at least one packet including the in- 
formation associated with at least one security 
association; and 

at least one security processor, connected to re- 
ceive the at least one packet from the at least one 
Ethernet controller for: 

locating the at least one security association 
using the information associated with at least 
one security association; and 
encrypting, decrypting or authenticating data 
using the security association. 

[0064] According to another aspect of the invention, 
a method of configuring a security processor is provided 
comprising: 

generating configuration information; 

formatting the configuration information into at least 

one packet; and 

sending the at least one packet over a Gigabit Eth- 
ernet network to a security processor. 

[0065] Advantageously, the at least one packet com- 
prises at least one IPsec packet. 
[0066] According to another aspect of the invention, 
a method of configuring a security processor comprises: 

receiving at least one packet containing configura- 
tion information over a Gigabit Ethernet network; 
extracting the configuration information from the at 
least one packet; and 

configuring a security processor using the extracted 
configuration information. 



[0059] Advantageously, the information comprises at 
least one address of the at least one security associa- 
tion. 

[0060] Advantageously, the at least one security proc- 
essor generates an IPsec header using the information. 
[0061] Advantageously, the at least one media ac- 
cess controller derives the information from context in- 
formation associated with the TCP operations. 
[0062] Advantageously, the at least one security proc- 
essor is an integrated circuit and the at least one media 
access controller is an integrated circuit. 
[0063] According to another asepct of the invention, 
a security processing system comprises: 

at least one Ethernet controller for: 

executing TCP operations and storing context 



[0067] Advantageously, the at least one packet com- 
prises at least one IPsec packet. 
[0068] According to another aspect of the invention, 
45 a method of configuring a security processor comprises: 



generating at least one security association; 
formatting the at least one security association into 
at least one packet; and 

sending the at least one packet over a Gigabit Eth- 
ernet network to a security processor. 



50 



55 



[0069] According to another aspect of the invention, 
a method of configuring a security processor comprises: 

receiving at least one packet containing at least one 
security association over a Gigabit Ethernet net- 
work; 
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extracting the at least one security association from 
the at least one packet; and 
storing the extracted at least one security associa- 
tion. 

5 

[0070] According to another aspect of the invention, 
a method of generating a TCP frame comprises: 

generating at least one header comprising an Eth- 
ernet header and a reference to an address of a se- to 
curity association; and appending the at least one 
header to an original TCP frame. 

[0071] According to another aspect of the invention, 
a method of processing a TCP frame comprises: 15 

receiving a TCP frame according to an Ethernet 
header; 

retrieving a security association from a data mem- 
ory using to a reference to an address of a security 20 
association in the TCP frame; and 
encrypting, decryp ting or authenticating at least a 
portion of the TCP frame using the security associ- 
ation. 

25 

[0072] According to another aspect of the invention, 
an in-line security processor comprises: 

at least one MAC; and 

at least one processor, connected to receive data 30 
from the at least one MAC and to send data to the 
at least one MAC, for encrypting, decrypting or au- 
thenticating at least a portion of the data. 

[0073] Advantageously, the at least one processor 35 
comprises at least one IPsec processor. 
[0074] Advantageously, the IPsec processor adds 
IPsec protocol elements to or removes IPsec protocol 
elements from the data. 

[0075] Advantageously, the processor further com- *o 
prises at least one data memory for storing security as- 
sociation information for use by the at least one proces- 
sor. 

[0076] Advantageously, the at least one processor 
hashes at least a portion of the received data to extract 45 
at least one address of the security association informa- 
tion. 

[0077] According to another aspect of the invention, 
a security processing system comprises: 

50 

at least network controller; and 

at least one security processor comprising: 

at least one cryptographic processor; and 
at least one MAC for sending packets to and 55 
receiving packets from the at least one network 
contrdler and for sending packets to and receiv- 
ing packets from at least one network. 



[0078] Advantageously, the at least one network con- 
troller adds information associated with at least one se- 
curity association to at least a portion of the packets sent 
to the at least one security processor. 
[0079] Advantageously, the at least one network con- 
troller adds at least one security header and trailer to at 
least a portion of the packets sent to the at least one 
security processor. 

[0080] Advantageously, the at least one security proc- 
essor modifies at least a portion of the at least one se- 
curity header and trailer added by the at least one net- 
work controller. 

[0081 ] Advantageously, the at least one security proc- 
essor modifies at least one checksum in the at least one 
security header added by the at least one network con- 
troller. 

[0082] Advantageously, the at least one network con- 
troller modifies at least one maximum transmitted unit 
size in accordance with modifications the security proc- 
essor makes to at least a portion of the packets. 
[0083] Advantageously, the at least one network con- 
troller reduces at least one TCP/IP payload size in ac- 
cordance with at least one security header and trailer 
size added to at least a portion of the packets. 
[0084] Advantageously, the at least one security proc- 
essor locates at least one security association accord- 
ing to a security parameter index contained in at least 
one packet received from the at least one network. 
[0085] Advantageously, the at least one security proc- 
essor locates at least one security association by hash- 
ing flow information from at least one packet received 
from the at least one network. 
[0086] Advantageously, the at least one network con- 
troller securely communicates with the at least one se- 
curity processor to configure the at least one security 
processor or retrieve status information from the at least 
one security processor. 

[0087] According to another aspect of the invention, 
a security processing method comprises: 

receiving, by a security processor, packets from a 
network connection; 

processing at least a portion of the received pack- 
ets, the processing consisting of at least one of the 
group of encrypting, decrypting and authenticating; 
and 

transmitting, from the security processor, over a 
network connection, packets comprising at least 
one result of the processing of the at least a portion 
of the received packets. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0088] These and other features, aspects and advan- 
tages of the present invention will be more fully under- 
stood when considered with respect to the following de- 
tailed description, appended claims and accompanying 
drawings, wherein: 
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Figure 1 is a block diagram of one embodiment of 
a security processing system constructed in ac- 
cordance with the invention; 
Figure 2 is a block diagram illustrating one embod- 
iment of packet data flow in the embodiment of Fig- 5 
ure 1; 

Figure 3 is a block diagram of one embodiment of 
a Gigabit network interface system constructed in 
accordance with the invention; 
Figure 4 is a block diagram of one embodiment of 10 
a security processor constructed in accordance 
with the invention; 

Figure 5 is a block diagram of one embodiment of 
an Ethernet controller constructed in accordance 
with the invention; *5 
Figure 6 is a flowchart representative of one em- 
bodiment of initialization and configuration opera- 
tions that may be performed in accordance with the 
invention; 

Figure 7 is a flowchart representative of one em- 20 
bodiment of outbound processing operations that 
may be performed in accordance with the invention; 
Figure 8 is a block diagram representative of one 
embodiment of outbound processing flow in accord- 
ance with the invention; 25 
Figure 9 is a flowchart representative of one em- 
bodiment of inbound processing operations that 
may be performed in accordance with the invention; 
Figure 1 0 is a block diagram representative of one 
embodiment of inbound processing flow in accord- 30 
ance with the invention; 

Figure 11 is a block diagram representative of one 
embodiment of inbound processing flow in accord- 
ance with the invention; 

Figure 12 is a flowchart representative of one em- 35 
bodiment of exception processing operations that 
may be performed in accordance with the invention; 
Figure 13 is a block diagram representative of Eth- 
ernet frame formats; 

Figure 1 4 is a block diagram representative of one *o 
embodiment of Ethernet frames with headers in ac- 
cordance with the invention; 
Figure 15 is a block diagram representative of one 
embodiment of IPsec packet processing in accord- 
ance with the invention; 45 
Figure 1 6 is a block diagram representative of one 
embodiment of configuration packet processing in 
accordance with the invention; 
Figure 1 7 is a block diagram representative of one 
embodiment of data packet processing in accord- so 
ance with the invention; 

Figure 1 8 is a block diagram of one embodiment of 
a network interface system constructed in accord- 
ance with the invention; 

Figure 1 9 is a flowchart representative of one em- ss 
bodiment of outbound processing operations that 
may be performed in accordance with the embodi- 
ment of Figure 1 8; 



Figure 20 is a block diagram representative of one 
embodiment of outbound processing flow in accord- 
ance with the embodiment of Figure 18; 
Figure 21 is a block diagram of one embodiment of 
a security processing system constructed in ac- 
cordance with the invention; 
Figure 22 is a block diagram of one embodiment of 
a security processing system constructed in ac- 
cordance with the invention; and 
Figure 23 is a block diagram of one embodiment of 
a security processing system constructed in ac- 
cordance with the invention. 

DETAILED DESCRIPTION 

[0089] The invention is described below, with refer- 
ence to detailed illustrative embodiments. It will be ap- 
parent that the invention can be embodied in a wide va- 
riety of forms, some of which may be quite different from 
those of the disclosed embodiments. Consequently, the 
specific structural and functional details disclosed here- 
in are merely representative and do not limit the scope 
of the invention. 

[0090] Figure 1 is a block diagram of one embodiment 
of a security processing system S constructed accord- 
ing to the invention. A security processor 1 1 8 in the sys- 
tem S is installed in the data path of a packet networ k 
to provide encryption, decryption, authentication and 
other security functions for data flowing through the 
packet network. The portions of the packet network con- 
nected to each side of the security processor 118 are 
labeled as packet network 1 1 6 and packet network 1 20. 
As used herein, the term security processor refers to 
one or more processing components that encrypt, de- 
crypt or authenticate data or perform any combination 
of these operations. 

[0091] In the example of Figure 1 data flows through 
the packet network between applications 112 executing 
on a host processor 1 1 0 and applications 1 24 executing 
on a host computing system 122. A media access con- 
troller (represented by block 114) provides, for example, 
ISO Layer 2 processing to provide the network inte rface 
for the host processor 110. In other embodiments, the 
block 114 may provide ISO Layer 3 and/or Layer 4 and/ 
or Layer 5 processing or processing for parts of those 
layers. For example, the block 114 may be a network 
processor (e.g., network controller). The host processor 
1 1 0 and a network processor 1 1 4 may cooperate to pro- 
vide packet processing to enable the applications 112 
to send and receive data over the packet network. The 
host computing system 1 22 performs similar packet op- 
erations as well as security operations complementary 
to those performed by the security processor 118. To 
reduce the complexity of Figure 1 the components that 
perform these packet and security operations are not 
depicted in the host computing system 1 22. 
[0092] The security processor 118 and the security 
operations of the host computing system 1 22 cooperate 
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to securely transmit selected data over the packet net- 
work 120. To this end, the security processor 118 and 
the host computing system 1 22 encrypt and/or authen- 
ticate the sele cted data before sending it over the pack- 
et network 1 20. In one embodiment, these security com- 
ponents generate IPsec packets. When the security 
processor 118 and the host computing system 122 re- 
ceive encrypted/authenticated packets they decrypt 
and/or authenticate the packets and forward them to the 
applications 112 and 124, respectively. For example, 
when the security processor 1 1 8 receives authenticated 
packets it may check the authentication of those packets 
before it forwards the packets to the host computing sys- 
tem 110. 

[0093] The security processor 118 includes network 
interface components (not shown) to enable the security 
processor 1 1 8 to send and receive data over the packet 
network. One network interface connects to the packet 
network 116 and another network interface connects to 
the packet network 1 20. In this way, the security proc- 
essor 1 1 8 is in -line with the data path of the packet net- 
work 116 and 120. In contrast, traditional security proc- 
essors connect to network processors via separate 
busses (e.g., a PCI bus or a POS -PHY interface) and 
are, therefore, outside the data path of the network. 
[0094] A device constructed according to this embod- 
iment of the invention may provide several advantages 
over conventional systems. A security processor may 
be s hared among several host processors. In addition, 
several security processors may be configured to pro- 
vide security services for a high -speed network. Also, 
the security processor may be located at a location that 
is remote from the location of the host processor. In this 
case, the network between the host processor and the 
security processor may need to provide a certain level 
of security. For example, a cryptographic "secret" may 
be shared between the host processor and the security 
processor. The ho st processor and the security proc- 
essor may use this "secret" to protect the configuration 
information, the status or errors reported, and/or other 
information transmitted between the host processor, the 
network controller and the security processor. 
[0095] A device constructed according to this embod- 
iment of the invention may be configured via the packet 
network. For example, the host processor 1 1 0 may send 
IPsec configuration packets to the security processor 
118 via the packet network 116. In addition, data used 
by the security processor 1 1 8 may be sent to the security 
processor 118 via the packet network. For example, the 
host processor 110 and/or the network processor 114 
may send packets containing security associations and 
information related to the sec urity associations (e.g., 
the addresses of the security associations) to the secu- 
rity processor 118 via the packet network 116. 
[0096] One implementation of the embodiment of Fig- 
ure 1 consists of a network interface card ("NIC") that 
connects to a motherboard of a computer system. The 
host processor resides on the motherboard and the net- 



work processor and the security processor reside on the 
NIC. In this implementation the packet network 116 may 
consist of a connection between the network processor 
and the security processor. 

5 [0097] One implementation of the embodiment of Fig- 
ure 1 consists of a LAN -on -Motherboard configuration. 
Here, the host processor and the network processor re- 
side on the motherboard. In this case, the security proc- 
essor may be implemented on the motherboard or may 

10 be implemented as a separate component that connects 
to the network processor. 

[0098] Typically, the packet network of Figure 1 would 
be an Ethernet network. In this case the network proc- 
essor 114 may be implemented as an Ethernet control- 
's ler that offloads Ethernet processing and other functions 
from the host processor 110. In addition, the security 
processor 118 may support IPsec. It should be under- 
stood, however, that the invention may be practiced us- 
ing other types of networks, network interfaces and se- 
20 curity protocols. 

[0099] Figure 2 illustrates one embodiment of TCP/IP 
and IPsec packet flow to and from a security processor 
210. In this example, outbound packet flow refers to 
packets sent from an Ethernet controller (not shown) to 
25 a packet ne twork (not shown). Inbound packet flow re- 
fers to data received from the packet network flowing to 
the Ethernet controller. 

[0100] The security processor 210 performs IPsec 
processing on a packet 21 2 received from the Ethernet 

30 controller and generates a packet 214 that is output to 
the packet network. The packet 21 2 includes header in- 
formation (L2, IP, TCP) and data. A portion of this header 
information (e.g., TCP) and the data may be encrypted/ 
authenticated during IPsec processing by the security 

35 processor 21 0. The output packet 214 includes the en- 
crypted/authenticated packet information (e.g., TCP, 
data), security information (ESP, ICV) and other header 
information (L2, IP). 

[0101] In a complementary operation, the security 

40 processor 210 performs IPsec processing on a packet 
216 received from the packet network and generates a 
packet 218 that is output to the Ethernet controller. The 
security processor 210 decrypts/authenticates the en- 
crypted/authenticated packet information (e.g., TCP, 

45 data) from the packet 216 and encapsulates the de- 
crypted/authenticated packet information (e.g., TCP, 
data) into the packet 218. Thus, the operation of an 
IPsec compliant security processor may include adding 
and/or removing IPsec protocol elements including, for 

so example, headers, trailers and/or other data. 

[0102] The security processor 21 0 may be configured 
using packets received over the packet network. A con- 
figuration packet 222 contains configuration data, a 
master control word ("MCW") and Layer 2 header infor- 

55 mation L2. If desired, the security processor 210 may 
be set up to send configuration packets 224 back to the 
Ethernet controller. 

[0103] The security processor 210 may be initially 
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configured so that it is configurable only from a "trusted" 
side of the network. This prevents unauthorized parties 
from altering the configuration of the security processor 
210 by hacking into the controller from the public net- 
work. In the example of Figure 2, the trusted (or secure) 5 
side is referred to as the "host" side and the other non 
-trusted (or non -secure) side, the "line" side. Hence, the 
security processor 210 may be configured using pack- 
ets received from the Ethernet controller. 
[0104] Typically, the security processor 210 will in- 10 
elude maintenance and error handling capabilities. For 
example, loopback paths are provided for inbound, out- 
bound and configuration packets. In addition, the secu- 
rity processor 210 sends error packets 220 to the Eth- 
ernet controller. In one embodiment, the error packets 15 
may include an MCW. 

[0105] A system constructed according to the inven- 
tion may provide several advantages over conventional 
systems. Simpler integration with other networking com- 
ponents may be achieved. As opposed to some PCI bus 20 
security processor implementations, traffic need not 
pass through the PCI bus up to three times. As opposed 
to some POS-PHY security processor implementations, 
multiple packets need not be buffered to converge two 
bi-directional connections into a single bi -directional 25 
connection. Thus, buffering and bandwidth problems 
may be reduced. Multiple connection technologies in a 
NIC may be avoided with the elimination of the POS 
-PHY interface. Relatively simple frame formats may be 
supported. A security processor may be located remote- 30 
ly. Thus, the security processor may be shared and/or 
dynamically allocated. These advantages are merely 
representative of advantages of invention. The inven- 
tion is not limited to these advantages. 
[0106] Referring now to Figures 3 - 5, one embodi- 35 
ment of a secure network interface for a Gigabit Ethernet 
application will be discussed. Such an embodiment may 
support, for example, IEEE standards 802.3ab, 802.3z 
and/or 802.3ae or any other speed or physical layer (e. 
g., SERDES). *o 
[0107] This embodiment of the invention may be im- 
plemented as a NIC that connects to a bus 318 (e.g. , 
PCI, PCI -X or PCI - Express, referred to hereafter gen- 
erally as a PCI bus) of a host computer (not shown) to 
connect the host computer to a Gigabit Ethernet network *s 
316. The NIC includes a network processor (Gigabit 
Ethernet controller 310) and a Gigabit security proces- 
sor 31 2. The controller 31 0 and the processor 31 2 may 
be implemented on the NIC in one or more integrated 
circuits. so 
[0108] The Gigabit Ethernet controller 310 includes 
standard controller components for interlacing with the 
busses. A PCI interface 320 provides connectivity to the 
PCI bus 318. A Gigabit MAC 328 provides connectivity 
to a Gigabit Ethernet network 31 4. 55 
[0109] In addition, the Gigabit Ethernet controller 31 0 
may include components for offloading TCP operations 
from the host processor (not shown). For example, the 



Gigabit Ethernet controller 310 may include a TCP/IP 
processor 322 that performs, for example, various TOE 
operations, packet assembly for outbound packets and 
packet disassembly for inbound packets. 
[0110] As depicted in Figure 3, the G igabit Ethernet 
controller 310 may include components that enable the 
Gigabit security processor 312 to more efficiently iden- 
tify packets that are to be encrypted/authenticated and 
to locate security association information for those pack- 
ets. For example, the Gigabit Ethernet controller 310 
may generate and/or store indexes to the security as- 
sociations used by the Gigabit security processor 312. 
To accelerate the operation of the Gigabit security proc- 
essor 31 2, the Gigabit Ethernet controller 31 0 may send 
these indexes to the Gigabit security processor 312 via 
a security identifier header. 

[0111] The Gigabit Ethernet controller 310 also may 
perform operations to account for packet overhead (e. 
g. t added IPsec headers, padding and trailer) that may 
be associated wi th the cryptography operations. For ex- 
ample, the Gigabit Ethernet controller 310 may support 
an updated path maximum transmitted unit ("MTU") size 
that takes into account the size of the IPsec header and 
trailer added by the Gigabit security processor 312. In 
this case, the Gigabit Ethernet controller 310 may re- 
duce the payload size accordingly. In embodiments 
where the Gigabit Ethernet controller 31 0 adds a secu- 
rity identifier header, the Gigabit Ethernet controller 310 
will further reduce the MTU for transmitted frames ac- 
cordingly. This may prevent creating IP fragments. In the 
embodiment of Figure 3, some or all of these operations 
may be performed by a security identifier header proc- 
essor 322. 

[0112] The Gigabit security processor 312 includes 
several components that support and perform cryptog- 
raphy (e.g., IPsec) operations. For example, an IPsec 
processor 342 processes packets associated with se- 
cure sessions. In some embodiments, the IPsec proc- 
essor 342 incorporates one or more encryption/decryp- 
tion/authentication processors 344 that encrypt, decrypt 
and/or authenticate packets received over the networks 
314 and 316. Security associations 340 used in the en- 
cryption/decryption/authentication operations are 
stored in internal and/or external data memory (not 
shown). A security identifier header processor 338 may 
be used to process security identifier headers received 
from the Gigabit Ethernet controller 31 0 to locate the se- 
curity associations 340. 

[0113] The Gigabit security processor 312 also in- 
cludes Gigabit MAC interfaces 336 and 346 for connect- 
ing the processor 312 to the Gigabit Ethernet networks 
314 and 316, respectively. In one embodiment the 
GMAC interfaces 336 and 346 comprise 10/100/1000 
Gigabit media access controllers ("GMACs") that are 
used in conjunction with integrated serial izer/dese rial iz- 
ers ("SERDES"). 

[01 14] In one embodiment, the Gigabit security proc- 
essor 31 2 interfaces with the network 31 6 via a network 
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PHY 348. In addition, Gigabit PHY interfaces (not 
shown) may be associated with the Gigabit MA Cs 328 
and 336 depending on the physical characteristics of the 
connection 314. For example, if the Gigabit Ethernet 
controller 310 and the Gigabit security processor 312 5 
are located on a common circuit board they may be con- 
nected without a full implement ation of a Gigabit Ether- 
net PHY If the Gigabit Ethernet controller 310 and the 
Gigabit security processor 312 are located remotely 
from one another via a Gigabit Ethernet network, a full 
implementation of a Gigabit Ethernet PHY may be used. 
[0115] In some e mbodiments, the PHY interfaces 
may be incorporated into the same integrated circuit as 
the MACs. For example, the PHY 348 may be incorpo- 
rated into an integrated circuit for the Gigabit security 
processor 312 that includes the Gigabit MAC 346. Fur- 
ther to the above, the components of Figure 3 may be 
implemented in various configurations. The processors 
322, 324, 338 and 342 and other components of the Gi- 
gabit Ethernet controller 310 and the Gigabit security 
processor 312 may be implemented, for example, in 
hardware and/or as software code executing on one or 
more processors. Some or all of these components may 
be implemented on one or more integrated circuits and/ 
or on common or separate circuit boards such as NIC 
and LAN -on-Motherboard solutions. 
[0116] The incorporation of the GMAC ports into the 
security processor gives it the capability to process data 
directly from the wire. A brief description of data flow 
through the system of Figure 3 for a secure session fol- 
lows. The host sends application data to the Gigabit Eth- 
ernet controller 310 via the PCI bus 318. The Gigabit 
Ethernet controller 310 encapsulates the data to form 
TCP/IP packets and sends the outbound packets to the 
Gigabit security processor 312 via connections 314 on 
the NIC. The Gigabit security processor 312 performs 
IPsec operations on the packets. These operations in- 
clude encrypting/authenticating the packets, and en- 
capsulating the encrypted/authenticated packets into 
IPsec packets by, for example, adding the IPsec header 
and trailer. These operations also may include updating 
the IP protocol field to point to the appropriate IPsec 
header type and compute and place the IP checksum 
when applicable (e.g., for IPv4) as it changes due to the 
presence of IPsec fields. These operations also may inc 
lude modifying other IP header fields such as IP length, 
as necessary. After these operations are performed, the 
Gigabit security processor 312 sends the resulting 
IPsec packets to the Gigabit network 316. 
[0117] Complementary operations are performed on 
inbound IPsec packets. The Gigabit security processor 
312 performs IPsec operations on IPsec packets re- 
ceived from the Gigabit network 31 6. These operations 
include unencapsulating the IPsec packets and decrypt- 
ing/authenticating the encrypted/authenticated packets. 
After removing the IPsec header and trailer, the Gigabit 
security processor 312 may reset the IP protocol field to 
6 (for TCP), recalculate the IP checksum (for IPv4) and 



replace the IP checksum with the newly calculated value 
The Gigabit security processor 312 sends the decrypt- 
ed/authenticated packets to the Gigabit Ethernet con- 
troller 310 via connections 314. The Gigabit Ethernet 
controller 31 0 then strips the TCP/IP packet header from 
the packet and sends the data to the host via the PCI 
bus 318. 

[01 18] In one embodiment, the Gigabit security proc- 
essor 312 and the Gigabit Ethernet controller 310 in- 
clude security identifier header processors 338 and 324, 
respectively, for processing special packet headers for 
packets associated with secure sessions. For outbound 
data, the security identifier header processor 324 en- 
capsulates the outbound TCP/IP packets with an outer 
security identifier header 330. Thus, the original TCP/IP 
packets comprise at least a portion of the data 334 for 
new packet. 

[01 1 9] The security identifier header 330 may include, 
for example, information that identifies the Gigabit se- 
curity processor 31 2. In one embodiment, this informa- 
tion consists of an address assigned to the Gigabit se- 
curity processor 312. 

[0120] The security identifier header 330 a Iso may 
include flow information 332 related to the secure ses- 
sion. In one embodiment, the flow information 332 in- 
cludes the address of the security association that the 
Gigabit security processor 312 must use to encrypt/au- 
thenticate the outbound TCP/IP packet. The Gigabit 
Ethernet controller 310 may generate this security as- 
sociation information when it builds the TCP/IP packets 
for the secure session. In this case, the Gigabit Ethernet 
controller 31 0 typically stores the security association 
information 326 with context information for the secure 
session. 

[0121] The security identifier header processor 338 
checks the packet to determine whether it should proc- 
ess the packet. For example, the security identifier 
header processor 338 may read the security identifier 
header to determine whether the header includes the 
address of the Gigabit security processor 31 2. If so, the 
security identifier header processor 338 retrieves the 
flow information 332 and strips the security identifier 
header 330 from the packet. The security identifier 
header processor 338 then retrieves the security asso- 
ciation 340 identified by the flow information 332 and 
sends the TCP/IP packet and the security association 
to the IPsec processor 342. The IPsec processor 342 
then encrypts/au thenticates the TCP/IP packet using 
the security association 340 and formats the encrypted/ 
authenticated packet into an IPsec packet. 
[01 22] In embodiments that use the security identifier 
header and flow information described herein, the Giga- 
bit security processor 31 2 may not need to perform com- 
putationally intensive security association lookup oper- 
ations for outbound traffic. As a result, the outbound op- 
erations to be performed by the Gigabit security proc- 
essor may essentially be limited to encryption/authentic 
ation, updating the IP header as described above, re- 
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placing the payload and inserting the trailer values when 
applicable. 

[0123] By supplying flow information in the packets, 
the embodiment described above provides an advanta- 
geous security processing solution. F or example, as s 
discussed below the system may meet fixed latency 
times for security association lookup and memory re- 
quirements may be reduced. In addition, this technique 
provides an effective manner of obtaining TCP informa- 
tion when the TCP functionality is provided in a hard- 
ware device. In the embodiment described above the 
TCP information does not need to be provided via a sep- 
arate bus or a side-band path. 
[0124] Figure 4 illustrates one implementation of a Gi- 
gabit security processor 410 that may provide the func- 
tionality of Gigabit security processor 312. This imple- 
mentation includes quad 10/100/1000 GMACs (receiv- 
ers 420A-D, transmitters 422A-D) with integrated SER- 
DES (receivers 424A -D, transmitters 426A - D). Each 
of the GMACs may be configured to interface with a host 
side network or a line side network. The network inputs 
and outputs for the GMACs are labeled P1 - P4. 
[0125] The Gigabit security processor 410 also in- 
cludes a PL3 interface. The input to the PL3 receiver 
436 is labeled PL3 TX. The output of the PL3 transmitter 
440 is labeled PL3 RX. 

[0126] One of the GMACs may be swapped with a 
PL3 interface. On the receive side, this is accomplished 
by a multiplexer 438 that selects either the signal from 
PL3 receiver 436 or the GMAC RX(4) 420D to be sent 
to a data input unit ("DIU") 428. On the transmit side, a 
demultiplexer 442 sends output data from a data routing 
unit ("DRU") 430 to either the PL3 transmitter 440 or the 
GMAC TX(4) 422D. 

[0127] The DIU 428 manages packet flow from the re- 
ceiver inputs into the processing path of the Gigabit se- 
curity processor 41 0 and may extract and process head- 
er information. Packets may be routed to a bypass path 
434, for example, when no security processing is nec- 
essary. This would be the case for non-IPsec packets 
flowing through th e Gigabit security processor 410. 
Packets may be routed to a public key processing com- 
ponent 432. Packets also may be routed to an IPsec 
processing component 412. The Gigabit security proc- 
essor 41 0 includes an internal data memory 41 4 as well 
a memory in terface component to access external data 
memory such as a serial dynamic random access mem- 
ory ("SDRAM") 416. Additional details of one embodi- 
ment of the processing path of a Gigabit security proc- 
essor are described in U.S. Patent Application No. 
09/610,798 filed on July 6, 2000 and entitled "DISTRIB- 
UTED PROCESSING IN A CRYPTOGRAPHY ACCEL- 
ERATION CHIP," the disclosure of which is hereby in- 
corporated by reference herein. 
[0128] The DRU 430 manages data from the process- 
ing path of the Gigabit security processor 41 0 to be sent 
to the device outputs. Thus, the DRU 430 routes packets 
to the GMAC transmitters 422A-C and the demultiplexer 



442. 

[01 29] Figure 5 illustrates one implementation of a Gi- 
gabit Ethernet controller 51 0 that may provide the func- 
tionality of Gigabit Ethernet controller 310. This imple- 
mentation includes processor or processors 518 (here- 
after generally "processor 518") for performing, among 
other tasks, TCP processing. Executable code for the 
TCP processing is stored in a data memory 522. 
[0130] The processor 518 stores TCP context infor- 
mation in a data memory 520 (e.g., a dedicated memo- 
ry). The data memory 520 may be accessible by all com- 
ponents of the Gigabit Ethernet controller 510 that may 
need access to data stored in the data memory 520. A 
data memory 524 provides additional data storage for 
the processor 518. 

[01 31 ] As discussed herein , the TCP context informa- 
tion may include flow and/or security association infor- 
mation that the Gigabit Ethernet controller 510 uses 
and/or sends to the Gigabit security processor 41 0. For 
example, this information may include the security as- 
sociation information 326 and/or flow information 332 
discussed above in conjunction with Figure 3. 
[01 32] Data flow in the Gigabit Ethernet controller 51 0 
is controlled, in part, by a memory contra Her 526 and a 
DMA controller 51 9. For example, the DMA controller 
519 is involved in managing data flow between the Gi- 
gabit network and the PCI bus. A PCI/PCI -X interface 
516 interfaces with the PCI/PCI-X bus that connects to 
the host computer (not shown). The memory controller 
526 also controls access to an internal buffer memory 
528 and an optional external data memory accessed via 
a memory interface. 

[0133] The Gigabit Ethernet controller 510 also in- 
cludes various support components. Phase lock loop 
circuits 530 and 538 provide clocks for the processor 
510. The processor 510 includes interfaces for external 
EEPROM 536, an SMBus 534 and LEDs 532. 
[0134] Additional details of embodiments of network 
interface and TOE structures and operations are de- 
scribed in the following U.S. patent applications: U.S. 

Patent Application No. , entitled 

"SYSTEM AND METHOD FOR TCP OFFLOAD," filed 
on August 29, 2003, Attorney Docket No. 13782US03; 

U.S. Patent Application No. , entitled 

"SYSTEM AND METHOD FOR NETWORK 
INTERFACING, " filed on August 29, 2003, Attorney 
Docket No. 13783US02; U.S. Patent Application No. 
, entitled "NETWORK INTERFAC- 
ING IN A MULTIPLE NETWORK ENVIRONMENT," filed 
on August 29, 2003, Attorney Docket No. 13945US02; 
and U.S. Provisional Patent Application No. 60/456,265 
filed March 20, 2003. Each of these patent applications 
is assigned to the same assignee as this application. 
The disclosures of these applications are hereby incor- 
porated by reference herein. 

[0135] Referring now to Figures 6-12, the operations 
of one embodiment of a security system constructed ac- 
cording to the invention will be treated in more detail. 
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Figure 6 describes configuration operations. Figures 7 
and 8 describe operations for outbound packets. Fig- 
ures 9, 1 0 and 1 1 describe operations for inbound pack- 
ets. Figure 12 describes operations for exception pack- 
ets. 5 
[0136] Figure 6 describes a few selected operations 
that may be performed after the system is reset. Blocks 
600 - 61 2 describe several operations of a security proc- 
essor. Blocks 614 - 632 describe several operations of 
a host processor. 10 
[01 37] When the security processor is reset as repre- 
sented by block 600, the security processor sets all host 
-side interfaces to return data back on the same channel 
from which it was received and sets all line side inter- 
faces to block all traffic. This may be accomplished by 15 
setting an appropriate default value for the MCW. In ad- 
dition, input signals may be used to set each GMAC to 
a host side or a line side configuration. 
[0138] After the security processor exits reset, the se- 
curity processor may default to a low power mode (block 20 
602) depending on the state of a LOW_PWR# input sig- 
nal. In low power mode the entire IPsec data path, the 
public key data path and external memory are disabled. 
For example, they may be placed in the low power state 
by gating their clock. Thus, only packets targeted at the 25 
bypass data path are allowed during this state. 
[0139] In one embodiment, the security processor is 
initialized (block 604) using a side band MDIO interface 
to control the integrated SERDES core and to initialize 
internal registers. In this embodiment, the MDIO inter- 30 
face: 1) configures the SERDES to the proper line 
speed; 2) releases the security processor from the low 
power state, hence it enables the IPsec data path; 3) 
sets MAC speed (10/100/1000); 4) sets the host side 
MAC to the promiscuous state; and 5) set the line side 35 
MAC to the promiscuous state (block 606). 
[0140] The rest of the configuration for the security 
processor may be initialized through the Ethernet con- 
troller by the host processor using configuration pack- 
ets. 40 
[0141] After a reset for a WakeOnLan mode of the se- 
cure NIC, the security processor is not released from 
the low power state. Instead, an MDC/MDIO interface 
is used to set up a pass through from the host side ports 
to the line side ports. This may be accomplished by pro- *s 
gramming an appropriate value for the default MCW and 
by releasing the block state on the line side port. 
[0142] The security processor accepts configuration 
accesses through any host side in terface (block 608). 
The host configuration packets are extracted from the 50 
Ethernet data packets. One embodiment of an extrac- 
tion process is described below. The extracted packet 
may contain the return Ethernet address (set by the 
host) for the processed configuration access packet. 
[0143] One embodiment of the invention supports 55 
four types of configuration packets: 1 ) register access 
packets (RAP); 2) memory access packets (MAP); 3) 
MODEXP access packets (MEP); and 4) flow update ac- 



cess packets (FAP). 

[0144] The host may use memory access packets to 
manage the layout and format information stored in the 
local memory of the security processor. The security 
processor executes each of the memory accesses co- 
herently and in correct order with data packets. The host 
may use a HostContext field in the configuration packets 
to add sequence numbers, processing tags, etc. to the 
packet. 

[0145] The local memory also stores security associ- 
ation information sent by the host processor (block 61 0). 
One embodiment of a security processor stores some 
of the security associations internally and, if necessary, 
stores additional security associations in an external 
memory such as a dual data rate SDRAM ("DDR 
-SDRAM"). The DDR -SDRAM configuration may be set 
by the host via a configuration access packet and stored 
in local EEPROM. 

[0146] After the security processor is configured it 
processes packet traffic as discussed herein (block 
612). 

[01 47] After the host processor is reset as represent- 
ed by block 614, the host processor configures the se- 
curity operations of the system (block 616). As repre- 
sented by dashed line 618, this includes some of the 
operations discussed in conjunction with block 608. 
[0148] The host processor also cooperates with an 
Ethernet controller to set up communication paths 
(block 620) and TCP sessions (block 622) with other 
host processors through the security processor's con- 
nections to the Ethernet network. 
[0149] In the case of secure sessions (block 624), the 
host processor generates unique security associations 
for each secure session (block 626). The host processor 
then sends the security associations to the security 
processor (block 628). As represented by dashed line 
630, this includes some of the operations discussed in 
conjunction with block 610. 

[0150] After the host processor completes these ini- 
tialization steps it processes packet traffic as discussed 
herein (block 632). 

[0151] Figure 7 describes a few selected operations 
that may be performed to process outbound packets. 
Blocks 71 6 - 730 describe several operations of a secu- 
rity processor 8 1 0 (Figure 8). Blocks 700 - 71 4 describe 
several operations of an Ethernet controller. In the de- 
scribed embodiment the Ethernet controller includes 
TCP offload capability as discussed herein. For embod- 
iments where the bulk of the TCP/IP processing is per- 
formed by the host processor, the host processor may 
perform the operations represented by blocks 704 - 71 4. 
[01 52] After the outbound operation begins as repre- 
sented by block 700, the Ethernet controller receives da- 
ta from the host processor (block 702). 
[01 53] As represented by block 704, the Ethernet con- 
troller performs TCP/IP processing as discussed herein 
to packetize the data from the host. As this process typ- 
ically involves building the packet, the Ethernet control- 



20 



25 



30 



35 



40 



45 



50 



13 



25 



EP1 427 133 A2 



26 



ler has ready access to the IP header inform ation such 
as the source address, the destination address and the 
protocol. In addition, the Ethernet controller has ready 
access to the TCP header information such as the 
source port and destination port. In some embodiments 5 
the Ethernet controller stores this information for each 
session in a context memory. This information may be 
used to uniquely define a flow in IPsec. Hence, this in- 
formation may be used to identify the security associa- 
tions associated with a given secure session (block 
706). Thus , the Ethernet controller may identify flow 
identifier information (e.g., a security association ad- 
dress, etc.) for the secure session (block 708). 
[0154] IPsec may assign one flow to multiple TCP 
connections that have the same IP flow (IP source and 
destination addresses) in common. Hence, a given set 
of flow identifier information may be used for multiple 
TCP connections. 

[0155] As represented by blocks 71 0 and 712 the Eth- 
ernet controller generates a security identifier header for 
the TCP/IP packet and encapsulates the TCP/IP packet 
and the flow identifier information with the security iden- 
tifier header. This operation may encompass the proce- 
dures discussed above in conjunction with Figure 3. 
[0156] In another embodiment, the Ethernet controller 
may add templates for the IPsec header and trailer to 
the packet. The security processor then performs the 
necessary IPsec operations. In this way, some of the 
header and trailer processing operations may be of- 
floaded from the security processor. 
[0157] The Ethernet controller then sends the packet 
to the security processor as represented by block 714. 
Figure 8 depicts one embodiment of an outbound packet 
81 2. Starting from the right side of the packet, the packet 
812 includes the Ethernet security identifier header, a 
CLASS -0 identifier (discussed below), and the original 
TCP/IP packet (Ethernet header, IP header and data). 
[0158] Turning now to the operations of the security 
processor 810, the security processor 81 0 handles four 
types of packets from the host side interface: 1 ) config- 
uration access packets (Class-FAMILY, CHIP); 2) out- 
bound IPsec packets (CLASS -0); 3) outbound IP pack- 
ets (DEFAULT_MCW); and 4) outbound non -IP packets 
(DEFAULT_MCW set MCW.NOP). The FAMILY, CHIP 
classification may be used to denote a particular family 
of chips for a manufacturer and a specific chip within 
that family. For example, a family of chips could define 
a manufacturer's security products. 
[01 59] When the security processor 81 0 receives the 
packet 812 (block 716), the security processor 810 
searches the Ether net type field in the security identifier 
header to determine the type of packet as listed above. 
Any non -IPsec or non -IP packets are passed through 
the security processor 81 0 essentially without modifica- 
tion. The security processor 810 may recalculate the 
Ethernet CRC. 

[01 60] If the security processor 81 0 determines that it 
should process the packet (block 71 8) the security proc- 



essor 810 strips the security identifier header (block 
720). 

[0161] Next, the security processor 810 attempts to 
retrieve the flow identifier information (block 722). All 
packets in the CLASS-0 format will have the flow iden- 
tifier in the packet. 

[0162] As represented by line 81 8, the security proc- 
essor 810 uses the flow identifier information to con- 
struct a direct address security association handle. The 
lower 22 bits of the FlowlD refer to the location of the 
security association in memory (e.g., local memory 
816). The upper two bits 822 of the 24-bit flow ID may 
be used to store the length of the security association. 
Figure 8 depicts one embo diment of a security associ- 
ation 820. 

[0163] The security processor 810 uses a default 
MCW for any packets that do not have a defined type. 
The host may set bits in the MCW to indicate that the 
packet should be dropped (MCW.DropPacket) or that 
the packet should be passed through (MCW.NOP). The 
security processor 810 processes any CLASS - FAMI- 
LY=security packets as configuration packets. 
[0164] The security processor 81 0 may be configured 
to drop any packets that do not contain a valid flow iden- 
tifier (range check on th e direct addresses). A deleted 
security association location must contain an MCW with 
the MCW.DropPacket bit set (an MCW of all zeros may 
be used to indicate a deleted security association that 
forces an exception packet). Any traffic that is intended 
to pass through the security processor 810 may be 
placed on a flow that indicates NOP in the MCW (by- 
passes IPsec processing). All other traffic is dropped (or 
returned as an error) by the security processor 810. 
[01 65] An inner Ethernet header that does not contain 
an IP packet may either be passed or dropped by the 
security processor 810. 

[01 66] In the configuration shown in Figure 8, the host 
has already performed the security association lookup. 
The direct address of the security association is passed 
in the CLASS -0 tag as the flow identifier. The result is 
a fixed latency through the security processor 810 as 
the security processor 81 0 does not need to do the flow 
lookup for any outbound packets. Moreover, this fixed 
latency may be obtained without the use of relatively ex- 
pensive content addressable memory or cache memory 
that might otherwise be used to identify or store the se- 
curity association for a given flow. 
[0167] As represented by blocks 724, 726 and 728, 
the security processor 810 retrieves the security asso- 
ciation data from memory, encrypts/authenticates the 
packet (e.g., packet 814) and assembles the IPsec 
packet. The resulting processed packet 814 contains 
the inner Ethernet header ready for transmission (mod- 
ified by the security processor 81 0 to contain the proper 
length for transmission on IP packets). As shown in Fig- 
ure 8, the packet 81 4 includes, from right to left, the inner 
Ethernet header, the outer IP header and IPsec infor- 
mation (ESP header, Initial Vector), the encrypted/au- 
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thenticated IP header and data, and the IPsec ESP trail- 
er. 

[0168] The security processor then transmits the 
packet 814 over the Ethernet network (block 730). 
[01 69] In some applications, a previously encapsulat- 
ed packet may be sent to the security processor 81 0 
using the CLASS - FAMILY=security packet type. This 
packet will be encrypted/authenticated by the security 
processor 81 0 using the security association data ("SA- 
Data") stored either in local memory or passed in -band 
with the packet. This format is required for some Micro- 
soft applications. A SAData.Cap_En bit may be set to 
zero to prevent the security processor 81 0 from attempt- 
ing encapsulation for these types of packets. 
[0170] Figure 9 describes a few selected operations 
that may be performed to process inbound packets. 
Blocks 900 - 91 4 describe several operations of a secu- 
rity processor 1010 (Figure 10). Blocks 916 - 920 de- 
scribe several operations of an Ethernet controller. 
[0171] As represented by block 902, the security proc- 
essor 1010 receives inbound packets 1012 (Figure 10) 
from the Ethernet network. Any packets that enter the 
security processor 1 01 0 from the LIN E side interface are 
tagged with a DEFAULT JvlCW that indicates an "in- 
bound" packet. The security processor 1010 may be 
configured to bypass inbound non-IPsec traffic (no 
lookup done on the packet). The inbound non-IPsec traf- 
fic may be forwarded to the host without modification. 
Any non -IP traffic also may be passed through to the 
host without modification. Configuration packets are not 
allowed on a line side interface. 
[0172] For inbound IPsec traffic where a SPI value 
can be controlled (block 904), the SPI may be used di- 
rectly by the security processor 1 01 0 to find the security 
association data as represented by line 1016 in Figure 
10. For example, the SPI may contain the address of 
the security association data 1020 in a memory 1018. 
The security processor performs a range check on all 
direct addresses to ensure that they are within the range 
of the established security association memory. Any di- 
rect access that is "out of range" is considered a flow 
not-found. 

[0173] At block 906 the security processor 1010 
checks the flow to determine whether the flow is within 
the range assigned to the security processor 1 01 0. The 
security processor 1110 may be configured to bypass 
any packets for which a flow is not found. This allows 
the host to terminate IPsec for the packet. The security 
processor 1 01 0 may be configured to either bypass in- 
bound flow miss packets (typical for a secure NIC, 
"SNIC," configuration) or flag them as errors (returned 
on the exception path). 

[0174] If IPsec processing behind the SNIC is re- 
quired (e.g., the SNIC is not offloading all of the possible 
sessions), the security processor allows data to pass 
through the device to the host. In general, the security 
processor may be configured to allow any inbound 
IPsec packet that is not found in the flow (or security 



association, SPI) lookup to be passed through to the 
host without any errors. 

[0175] If at block 906 the flow is within the range as- 
signed to the security processor 1 01 0, the security proc- 

s essor 1010 unencapsulates the IPsec packet (block 
908), retrieves the security association (block 910) and 
decrypts/authenticates the encrypted/authenticated IP 
header and data (block 912). As depicted in Figure 10, 
an SAUpdate field in the security association data 1 020 

10 may be used to point to updateable security association 
fields 1022. The security processor 1010 sends the re- 
assembled packet 1 01 4 to the Ethernet controller (block 
914). 

[0176] After the Ethernet controller receives the pack- 
15 et (block 916), the Ethernet controller unencapsulates 
the packet (block 918) and sends the data to the host 
processor (block 920). 

[0177] Figure 11 depicts one example of IPsec traffic 
flow for an embodiment that accounts for the situation 
20 where the SPI value cannot be control led in some of 
the incoming packets. In this case, the security proces- 
sor 1110 retrieves the SPI, destination address ("DA") 
and protocol ("PROTO") fields of the packet and, as rep- 
resented by lines 1 1 06 and 1114, performs a hash algo- 
us rithm into the inbound flow table 1112 and 1116 to find 
the security association 1120 in the memory 1108. In 
one embodiment, the security processor 1110 performs 
an exact match search to verify that it has found the 
proper security association. 
30 [0178] A decrypted packet may be return ed by the 
security processor 1110 without removing the decapsu- 
late (as required for some implementations) if SAData. 
Cap_En=0. 

[0179] Referring to Figure 1 2, the security processor 

35 1210 may return exception packets over the GMAC host 
side interface. Any exception packets (inbound or out- 
bound) 1212 are returned to the exception path (set to 
the GMAC host side interface for a SNIC configuration). 
The security processor 1210 adds a programmable 

40 header 1 21 6 to the error packet 1214. For example, this 
may be an Ethernet header with a tag set in the TYPE 
field to the return host. If the added header is Ethernet, 
the security processor 1210 calculates the proper Eth- 
ernet length field. 

45 [0180] In one embodiment, the security processor 
1 21 0 returns error packets with only one type of header. 
In this case, the host may have to parse the MCW and 
PacketStatus fields that may be in the packet. 
[0181] With the above description in mind, one em- 

50 bodiment of Ethernet header processing will now be dis- 
cussed in conjunction with Figures 13-17. Referring 
initially to Figure 13, if the IP header is framed by an 
Ethernet MAC header then the security processor will 
calculate the offset to the IP header. There are four sup- 

55 ported Ethernet types, each with a different offset to the 
IP header: 

1) Ethernet II (IEEE 802.3) (1310 in Figure 13); 
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2) Ethernet SNAP (IEEE 802.3, RFC 1042) (1312 
in Figure 13); 

3) Ethernet II VLAN (IEEE 802.3, IEEE 802.3ac) 
(1314 in Figure 13); and 

4) Ethernet SNAP VLAN (IEEE 802.3, IEEE 5 
802.3ac) (1316 in Figure 13). 

[01 82] Referring now to Figure 1 4, two types of pack- 
ets 1400 and 1402 are shown. The DA fields contain a 
destination address. The SA fields contain a source ad- 
dress. S.P. represents an address of a security proces- 
sor. 

[0183] The security processor processes the Ethernet 
head er (e.g., outer header 1410) to extract in -band 
communication over a host side interface. The packet 
is identified using the Ethernet "TYPE" 141 6 field of the 
Ethernet header. A company may have a unique regis- 
tered Ethernet "TYPE" 1416 that defines the in-band 
packet communication. This "TYPE" is registered with 
the IEEE. This mechanism may be used for any of the 
supported Ethernet formats. 

[01 84] The security processor recogn izes two formats 
of this custom in-band communication scheme. The first 
format (CLASS-0) is intended for all devices of a com- 
pany where a flow tag has been used to identify the 
unique "flow" for a packet. One embodiment of such a 
packet is the top packet 1 400 of Figure 1 4. The first byte 
1426 of the MFGJHDR 1412 is always zero to indicate 
that the MFGJHDR 1412 is four bytes and contains a 
3-byte flow identifier ("FlowlD"). 
[0185] The second format (CLASS -F for FAMILY) is 
used on a per chip basis for configuration access that is 
defined by the device. One embodiment of such a pack- 
et is the lowe r packet 1 402 of Figure 1 4. If the first byte 
1 420 is non -zero, the information that follows (i.e. , block 
1422) is ignored by all devices except the assigned 
class. For example, all security devices made by a man- 
ufacturer may use a prefix of 0x58 as the first byte 1 420 
to indicate the security processor class. The next byte 
1422 is defined as the subclass or device family ID. A 
value of 0x45 may be used for the security processor. 
This two-byte code automatically aligns the next word 
of the configuration packet (the MCW) to a 32-bit bound- 
ary. 

[0186] Referring to the CLASS-0 case of Figure 15, 
the security processor strips off the outer Ethernet head- 
er 1516 containing the manufacturer ("MFG") Ethernet 
type 1518 from an input packet 1510. When the security 
proc essor finds a CLASS -0 MFGJHDR 1518 the se- 
curity processor adds a CLASS0_MCW value and uses 
the FlowlD as the security association pointer 
("SA_PTR") along with a default security association 
length ("SA_LEN") to construct a "direct" security asso- 
ciation handle ("SAHandle") field for the packet 1512 
shown in Figure 15. The upper two bits of FlowlD are 
used to select up to four different default lengths. The 
SAData Structure should be one of four default lengths 
for all security associations when using this mode. Typ- 



ically there would be one length for transport packets 
and another for tunnel packets. After IPsec processing, 
the security processor outputs a packet 1514. 
[0187] Referring to the CLASS -F case of Figure 1 6, 
the processing for a CLASS -F-C MFGJHDR invo Ives 
processing class ("F") and sub -class ("C") for the cur- 
rent chip as discussed above. The security processor 
discards the original header 1614 and the two bytes of 
CLASS/SUB -CLASS 1618, 1616 of the input packet 
1 61 0. This results in a 32 bit aligned M CW that is proc- 
essed by the security processor. The configuration 
packet 1 61 2 is returned to the host via the second Eth- 
ernet header, which should be properly formatted by the 
host. 

[01 88] The security processor also may allow an Eth- 
ernet header to be embedded in the configuration pack- 
et depicted in Figure 16. When the Ethernet header is 
embedded in a non-data packet type, the four -byte OxF 
-C code is used to align a RegisterAccessWord to a 32 
-bit boundary (already aligned on input). The security 
processor does not change this Ethernet header prior 
to being sent. Therefore, the host should predict the size 
of the resulting packet with the proper Ethernet length. 
[0189] Referring to Figure 1 7, the security processor 
CLASS -F packet type may be used to send a regular 
pa cket with a host constructed MCW that matches the 
packet formats. In this case, the Ethernet header is han- 
dled normally. The security processor recalculates the 
Ethernet header length and adds/removes the gap be- 
tween the Ethernet header and the IP header to gener- 
ate the output packet 1 71 2. 

[0190] The above discussion illustrates one example 
of how the invention may be implemented. It should be 
understood, however, that the invention may be prac- 
ticed using other packet processing techniques. For ex- 
ample, information similar to that described above may 
be inserted into conventional headers. In addition, the 
system could be configured to not add the special head- 
er yet always assume that the header is present. In this 
case, the system could add a simple tag to the header 
(even in front of the header). Furthermore, the outer 
header could be omitted and the security processor con- 
figured to assume that all packets received from a given 
source will be in bytes. In addition, the security proces- 
sor could be configured to add the inner Ethernet head- 
er. 

[0191] Also, different implementations may be used 
to locate the security association information. For exam- 
ple, rather than using the FlowlD, a hashing algorithm 
may be used on the source address, destination ad- 
dress, protocol, source port and destination port. The 
FlowlD may be calculated by other components in the 
system. The FlowlD may include other information re- 
lated to the security association other than a direct ad- 
dress. 

[0192] Referring now to Figures 1 8 - 20, one of these 
alternate embodiments will be discussed in more detail. 
In this embodiment a security processor 1 81 2 operates 
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in an essentially transparent manner with respect to an 
Ethernet controller 1810. For example, the Ethernet 
controller 1810 does not provide a security identifier 
header to the security processor 1812 as discussed 
above. Rather, the security processor may independ- 5 
ently locate security association for a secure flow by a 
direct lookup or hashing flow information from the pack- 
ets. 

[0193] The Ethernet controller 1810 includes stand- 
ard controller components for interfacing with the 
busses as discussed in previous embodiments. For ex- 
ample, a PCI interface 1 820 provides connectivity to the 
PCI bus 1 81 8 and a MAC 1 828 provides connectivity to 
an Ethernet net work 1814. These or similar compo- 
nents may be selected to support various data bus and 
network standards and associated data rates. 
[0194] In addition, the Ethernet controller 1810 may 
include components for offloading TCP operations from 
the host processor (not shown). For example, the Eth- 
ernet controller 1810 may include a TCP/IP processor 
1 822 that performs, for example, various TOE opera- 
tions, packet assembly for outbound packets and packet 
disassembly for inbound packets. 
[0195] The Ethernet controller 1810 also may perform 
operations to account for packet overhead (e.g., added 
packet headers) that may be associated with the cryp- 
tography operations. For example, the Ethernet control- 
ler 1 81 0 may support an updated path maximum trans- 
mitted unit ("MTU") size that takes into account the size 
of the IPsec header and trailer added by the security 
processor 1812. In this case, the Ethernet controller 
1 81 0 may reduce the TCP/IP payload size accordingly. 
This may prevent creating IP fragments. 
[0196] The security processor 1 81 2 includes several 
components that perform cryptographic operations 
such as IPsec. For example, an IPsec processor 1842 
processes packets associated with secure sessions. In 
some embodiments, the IPsec processor 1 842 incorpo- 
rates one or more encryption/decryption/authentication 
processors 1844 that encrypt/decrypt/authenticate 
packets received over the networks 1814 and 1 81 6. Se- 
curity associations 1 840 used in the encryption/decryp- 
tion/authentication operations are stored in internal and/ 
or external data memory (not shown). 
[0197] The security processor 1812 also may include 
MAC interfaces 1836 and 1846 for connecting the se- 
curity processor 1812 to the Ethernet networks 1814 
and 1816, respectively. In one embodiment the MAC in- 
terfaces 1836 and 1846 comprise 10/100/1000 Gigabit 
media access controllers ("GMACs") that are used in 
conjunction with integrated serializer/deserializers 
("SERDES"). 

[0198] In one embodiment, the security processor 
1 81 2 interfaces with the network 1 81 6 via an integrated 
network PHY 1848. In addition, PHY interfaces (not 
shown) may be associated with the MACs 1828 and 
1836 depending on the physical characteristics of the 
connection 1814. For example, if the Ethernet controller 



1810 and the security processor 1 81 2 are located on a 
common circuit board they may be connected without a 
full implementation of an Ethernet PHY. If the Ethernet 
controller 1810 and the security processor 1812 are lo- 
cated remotely from one another via an Ethernet net- 
work, a full implementation of an Ethernet PHY may be 
used. 

[0199] The PHY interfaces may or may not be incor- 
porated into the same integrated circuit as the MACs. 
For example, as represented by Figure 1 8 the PHY 1 848 
may be incorporated into an integrated circuit for the se- 
curity processor 1812 that includes the MAC 1846. In 
other embodiments, the PHYs (e.g., PHY 1848) may be 
implemented in a separate integrated circuit. 
[0200] Furthertothe above, the components of Figure 
1 8 may be implemented in various configurations. The 
components of the Ethernet controller 1810 and/or the 
security processor 1812 may be implemented, for ex- 
ample, in hardware and/or as software code executing 
on one or more processors. Some or all of these com- 
ponents may be implemented on one or more integrated 
circuits and/or on common or sepa rate circuit boards 
such as NIC and LAN-on-Motherboard solutions. 
[0201 ] Referring now to Figures 1 9 and 20, a brief de- 
scription of data flow through the system of Figure 1 8 
for a secure session follows. Several operations of the 
Ethernet controller 1810 are represented in Figure 19 
by blocks 1902 - 1906. Several operations of the secu- 
rity processor 1812 are represented by blocks 1908 - 
1 922. Figure 20 illustrates one embodiment of process- 
ing flow for the system of Figure 1 8. 
[0202] Beginning at block 1 900 in Figure 1 9, the host 
sends application data to the Ethernet controller 1810 
via the PCI bus 1818 (block 1902). As represented by 
block 1 904, if the Ethernet controller 1 81 0 supports TOE 
operations it may perform some of the TCP processing 
for the host. In addition, the Ethernet controller 1 81 0 en- 
capsulates the data to form TCP/IP packets that may be 
sent over an Ethernet network. As represented by block 
1906, the Ethernet controller 1810 then sends the out- 
bound packets to the security processor 1812 via con- 
nections 1814. 

[0203] Figure 20 depicts one embodiment of an out- 
bound TCP/IP packet. Starting from the right side of 
TCP/IP packet 2012, the packet 2012 includes an Eth- 
ernet header, an IP header and data. 
[0204] After the security processor 1 81 2 receives the 
packets (block 1 908), it may extract information from the 
packets to determine whether the packets are associat- 
ed with a secure flow (block 1910). If the packets are 
not associated with a secure flow, the security processor 
1 81 2 forwards the packets to the network as represent- 
ed by block 1922. 

[0205] If the packets are associated with a secure 
flow, as represented by block 1912, the security proc- 
essor 1812 may extract flow information from the pack- 
ets to locate security association information for the 
packet. The flow information may include, for example, 
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source address, destination address, protocol, source 
port and destination port information for the packets. 
[0206] As represented by block 1 91 4 and by line 201 6 
in Figure 20, in some embodiments the security proces- 
sor 1 81 2 may hash this flow information to, for example, 5 
generate an index into a table that contains addresses 
of security association information stored in a data 
memory (e.g., local memory 2018). Once the address 
of the security association is determined, the security 
processor 1812 retrieves the security association infor- 
mation from the data memory 201 8 (block 1916). 
[0207] In an alternative embodiment, the security 
processor 1 81 2 may locate a security association using 
a SPI from a received packet as discussed above. In 
some embodiments the SPI is compared against stored 
SPI values to access the security association informa- 
tion. In this case, the security processor 1812 may per- 
form a direct lookup into the data memory 2018. 
[0208] The security processor 1812 may then perform 
cryptography (e.g., IPsec) operations on the packets. As 
represented by block 1918, these operations may in- 
clude encrypting/authenticating outbound packets and, 
as represented by block 1920, encapsulating the en- 
crypted/authenticated packets into IPsec packets by, for 
example, adding an IPsec header and trailer. These op- 
erations also may include updating the IP protocol field 
to point to the appropriate IPsec header type and IP 
checksum when applicable (e.g., for IPv4) as it changes 
due to the presence of IPsec fields. These operations 
also may include modifying other IP header fields such 
as IP length and checksum, as necessary. 
[0209] As represented by block 1 922, a fter these op- 
erations are performed, the security processor 1812 
sends the resulting packets to the Ethernet network 
1816. Figure 20 depicts one embodiment of an IPsec 
packet 201 4 that may be generated by the security proc- 
essor 1812. 

[021 0] Complementary operations may be performed 
on inbound IPsec packets. For example, the security 
processor 1812 and the Ethernet controller 1810 may 
perform inbound packet operations similar to those dis- 
cussed above. 

[021 1] Figure 21 depicts an embodiment of a system 
constructed according to the invention where one or 
more security processors 2110 provide services to one 
or more Ethe met controllers (or other networking de- 
vices) 2112. In this embodiment, the security processor 
2110 is connected using switch 2114 as a backplane or 
fabric. The interconnection of other devices such as host 
processors, network processors or external ports is pos- 
sible in this configuration. Outbound packet flow is from 
the Ethernet controllers 2112 over networks 2121 
through the switch 211 4, to the security processor 2110 
via network 2120 and out to the network 2122. Inbound 
traffic flow is in the opposite direction. Thus, the switch 
2114 distributes or collects packets between Ethernet 
controllers (or MACs) and the security processor. 
[0212] The security processor 2110 is managed over 



the switch fabric by one or more host processors (e.g., 
CPU 21 1 6). For example, the host processors 21 1 6 may 
configure the security processor 21 1 0 when the security 
processor is reset. In addition, the host processors 2116 
may allocate the address space in the security proces- 
sor 21 1 0 to each of the Ethernet controller 21 1 2 as each 
Ethernet controller 2112 comes on line. This address 
space may be used to store the security association in- 
formation for sessions associated with each Ethernet 
controller. In this case, the Ethernet controllers 2112 
may be configured to request access to the security 
processor 2110 from the host processors 211 6. 
[021 3] In one embodiment, the switch 21 1 4 adds a vir- 
tual LAN ("VLAN") tag to the packets received over net- 
works 2118 from the Ethernet controllers 2112. In this 
way, the security processor 2110 may determine as to 
which Ethernet controller 2112 a given packet is asso- 
ciated. 

[0214] From the above, it should be appreciated that 
by providing packet network connectivity in the security 
processors, communications with the security proces- 
sors may be achieved through network fabric such as a 
switch. Moreover, this may be accomplished using the 
same connectivity and procedures that may be used for 
directly connected devices (e.g., a SNIC implementa- 
tion). 

[0215] In one embodiment, the switching system de- 
scribed herein is implemented as a chassis -based 
switch. For example, the chassis-based switch may in- 
clude a backplane into which several blades (e.g., circuit 
cards) are plugged for interconnectivity. The switch/ 
switching fabric is implemented as a switch blade in the 
chassis-based switch. An Ethernet controller and/or 
MAC may be incorporated into a processing blade in the 
chassis -based switch. A security processor may be in- 
corporated into a switching blade in the chassis -based 
switch. 

[0216] Figure 22 illustrates one embodiment of inter- 
connections between a security processor 221 2 and an 
Ethernet controller on a SNIC. The Ethernet controller 
221 0 drives a reference clock 2222 and a system reset 
signal 2224. An MDC/MDIO interface 2216, 2214 may 
be used to configure the S ERDES interface ports 221 8 
and 2228 on the security processor 221 2. This interface 
may also be used to issue a reset (via register reset) 
and control the power state of the security processor 
221 2. The control provided by the MDC/MDIO interface 
may be used to configure the security processor during 
WakeOnLan mode. The security processor 2212 pro- 
vides the link status of the line side SERDES 2228 to 
the host via a side band link 2220. When the 
LOW_PWR# input pin 2230 is tied to zero the security 
processor 221 2 exits reset in a low power state. 
[0217] Figure 23 depicts an embodiment of a system 
constructed according to the invention where several 
security processors 231 0, 231 2 provide services to net- 
working devices (not shown) via switch 2320. As repre- 
sented by the ellipse 2324, two or more security proc- 
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essors may be configured to provide security process- 
ing. The security processors 2310, 2312 are managed 
over the switch fabric by one or more control processors 
2322. In one embodiment a 10 Gbit Ethernet controller 
connects to the system via Ethernet network 231 4. The 5 
switch 2320 distributes and collects the traffic to/from 
the security processors 2310, 2312, etc. to provide 
IPsec processing at 10 Gbits over a packet network 
2316, 2318, etc. 

[0218] It should be apprec iated that the inventions 
described herein are applicable to and may utilize many 
different protocols and standards and modifications and 
extensions of those protocols and standards including, 
for example and without limitation, IP, TCP, UDP, ICMP, 
IPsec, SSL and FCsec. Moreover, a variety of crypto- 
graphic and signature algorithms and modifications and 
extensions thereof may be used. The invention may be 
practiced using tunnel mode and/or transport mode 
packet processing. 

[0219] In addition, a system constructed according to 
the invention may be implemented on a variety of data 
networks including, without limitation, fiber channel, 
Ethernet, ATM and FDDI. Thus, the interfaces dis- 
cussed herein such as the MAC and PHY would support 
the corresponding data network. 
[0220] It should also be appreciated that the inven- 
tions described herein may be constructed using a va- 
riety of physical components and configurations. For ex- 
ample, a variety of hardware and software processing 
components may be used to implement the functions of 
the host processors, security processors, network proc- 
essors, Ethernet processors/controllers and other com- 
ponents. 

[0221] These processing components may be imple- 
mented, without limitation, in a processor, a state ma- 
chine or other hardware, or any combina tion of these 
and may involve execution of software, firmware or oth- 
er code. These components may be combined on one 
or more integrated circuits. For example, several of 
these components may be combined within a single in- 
tegrated circuit. Some components may be implement- 
ed as a single integrated circuit. Some components may 
be implemented using several integrated circuits. 
[0222] The components and operations discussed 
herein may be applicable to various other embodiments. 
For example, the components and operations described 
with respect to one of the described embodiments may 
be substituted or incorporated into other embodiments. 
[0223] In addition, the components and functions de- 
scribed herein may be connected/coupled in many dif- 
ferent ways. The manner in which this is done may de- 
pend, in part, on whether and how the components are 
separated from the other components. Some of the con- 
nections represented by the lead lines in the drawings 
may be in an integrated circuit, on a circuit board, or over 
a backplane to other circuit boards. In some embodi- 
ments, the lead lines may represent a data network such 
as a local network and/or a wide area network (e.g., the 



Internet). Thus, some of the components may be locat- 
ed in a remote location with respect to the other compo- 
nents. In addition, these connections/couplings may be 
made with physical wire, fiber and/or wireless connec- 
tions, for example. 

[0224] Moreover, the signals discussed herein may 
take several forms. For example, in some embodiments 
a signal may be an electrical signal transmitted over a 
wire. Signals as discussed herein also may take the 
form of data. For example, in some embodiments an ap- 
plication program may send a signal to another applica- 
tion program. Such a signal may be stored in a data 
memory. 

[0225] The co mponents and functions described 
herein may be connected/coupled directly or indirectly. 
Thus, in some embodiments there may or may not be 
intervening devices (e.g., buffers) between connected/ 
coupled components. 

[0226] A wide variety of devices may be used to im- 
plement the data memories discussed herein. For ex- 
ample, a data memory may comprise one or more RAM , 
disk drive, SDRAM, FLASH or other types of data stor- 
age devices. 

[0227] The invention may be practiced using different 
types of cipher engines. For example, in one embodi- 
ment of the invention data is decrypted using a block 
cipher or a stream cipher. 

[0228] In summary, the invention described herein 
teaches improved security processing techniques. 
While certain exemplary embodiments have been de- 
scribed in detail and shown in the accompanying draw- 
ings, it is to be understood that such embodiments are 
merely illustrative of and not restrictive of the broad in- 
vention. In particular, is should be recognized that the 
teachings of the invention apply to a wide variety of sys- 
tems and processes that are configurable. It will thus be 
recognized that various modifications may be made to 
the illustrated and other embodiments of the invention 
described above, without departing from the broad in- 
ventive scope thereof. In view of the above it will be un- 
derstood that the invention is not limited to the particular 
embodiments or arrangements disclosed, but is rather 
intended to cover any changes, adaptations or modifi- 
cations which are within the scope and spirit of the in- 
vention as defined by the appended claims. 
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50 1. A security processing method comprising: 

receiving, by a security processor, packets from 
a Gigabit Ethernet network; 
processing at least a portion of the received 
55 packets, the processing consisting of at least 

one of the group of encrypting, decrypting and 
authenticating; and 

transmitting, from the security processor, at 
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least one result of the processing of the at least 
a portion of the received packets. 

2. A security processor comprising: 



at least one security processor, connected to 
receive the at least one packet from the at least 



one media access controller for: 

locating the at least one security associa- 
tion using the information; and 
5 encrypting, decrypting or authenticating 

data using the security association. 

7. A security processing system comprising: 

at least one Ethernet controller for: 

executing TCP operations and storing con- 
text information associated with the TCP 
operations; 

generating information associated with at 
least one security association from the 
context information; and 
generating at least one packet including 
the information associated with at least one 
security association; and 

at least one security processor, connected to 
receive the at least one packet from the at least 
one Ethernet controller for: 

locating the at least one security associa- 
tion using the information associated with 
at least one security association; and 
encrypting, decrypting or authenticating 
data using the security association. 

8. A method of configuring a security processor com- 
prising: 

generating configuration information; 
formatting the configuration information into at 
least one packet; and 

sending the at least one packet over a Gigabit 
Ethernet network to a security processor. 

9. A method of configuring a security processor com- 
prising: 

receiving at least one packet containing config- 
uration information over a Gigabit Ethernet net- 
work; 

extracting the configuration information from 
the at least one packet; and 
configuring a security processor using the ex- 
tracted configuration information. 

10. A method of configuring a security processor com- 
prising: 

generating at least one security association; 
formatting the at least one security association 
into at least one packet; and 
sending the at least one packet over a Gigabit 



at least one Gigabit MAC; and 
at least one processor, connected to send data 
to and receive data from the at least one Gigabit 
MAC, for encrypting, decrypting or authenticat- 
ing at least a portion of the data. 10 

3. An in-line security processor comprising: 

a plurality of Gigabit MACs; and 
at least one processor, connected to receive 15 
data from at least one of the Gigabit MACs and 
to send data to at least one of the Gigabit 
MACs, for encrypting, decrypting or authenti- 
cating at least a portion of the data. 

20 

4. A security processing system comprising: 

at least one media access controller; 
at least one security processor; and 
at least one switch for distributing or collecting 25 
packets between the at least one media access 
controller and the at least one security proces- 
sor. 

5. A chassis-based switch comprising: 30 

at least one backplane; 
at least one processing blade connected to the 
at least one backplane, the at least one 
processing blade comprising at least one me- 35 
dia access controller; and 
at least one switching blade connected to the 
at least one backplane, the at least one switch- 
ing blade comprising: 

40 

at least one security processor; and 
at least one switch for routing packets be- 
tween the at least one media access con- 
troller and the at least one security proces- 
sor. 45 

6. A security processing system comprising: 

at least one media access controller for: 

50 

executing TCP operations; 
generating information associated with at 
least one security association; and 
generating at least one packet including 
the information; and ss 
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Ethernet network to a security processor. 

11. A method of configuring a security processor com- 
prising: 

receiving at least one packet containing at least 
one security association over a Gigabit Ether- 
net network; 

extracting the at least one security association 
from the at least one packet; and 
storing the extracted at least one security as- 
sociation. 

12. A method of generating a TCP frame comprising: 

generating at least one header comprising an 
Ethernet header and a reference to an address 
of a security association; and appending the at 
least one header to an original TCP frame. 

13. A method of processing a TCP frame comprising: 

receiving a TCP frame according to an Ethernet 
header; retrieving a security association from a 
data memory using to a reference to an address 
of a security association in the TCP frame; and 
encrypting, decryp ting or authenticating at 
least a portion of the TCP frame using the se- 
curity association. 

14. An in-line security processor comprising: 

at least one MAC; and 

at least one processor, connected to receive 
data from the at least one MAC and to send da- 
ta to the at least one MAC, for encrypting, de- 
crypting or authenticating at least a portion of 
the data. 

15. A security processing system comprising: 

at least network controller; and 

at least one security processor comprising: 

at least one cryptographic processor; and 
at least one MAC for sending packets to 
and receiving packets from the at least one 
network contrdler and for sending packets 
to and receiving packets from at least one 
network. 

16. A security processing method comprising: 

receiving, by a security processor, packets from 
a network connection; 

processing at least a portion of the received 
packets, the processing consisting of at least 
one of the group of encrypting, decrypting and 



authenticating; and 

transmitting, from the security processor, over 
a network connection, packets comprising at 
least one result of the processing of the at least 
5 a portion of the received packets. 
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